fix(portal): replace display-name editing with a Handle row - #6
Merged
Conversation
The server deletes PUT /v1/auth/display-name. Drop the account page's Display name row and updateDisplayName helper rather than repoint it at handle-claim (out of scope). Email row already covers identity.
Replaces the removed display-name editor's slot with a Handle row: viewable by everyone with a Copy button, editable via a Change handle modal for Pro and above. Free users see the value plus a note that they're still reachable. A lapsed-Pro user keeps their custom handle and the edit gate is only ever on current tier, never handle_is_custom.
ChangeHandleModal: the post-rename getMe() refetch shared a try with updateHandle(), so a network blip on the refetch reported a successful rename as "Failed to update handle." Give it its own try/catch and fall back to the trimmed input on failure. Also strip a leading "@" before validating, since the server accepts it and the UI's own subtitle models the handle as "@name". page.tsx: guard the Pro-only "Change handle" button against the null tier during initial load, and hide Copy when there is no handle to copy.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The portal was never updated when the app moved to handles, so it still had a live Display name editor calling
PUT /v1/auth/display-name— a route VoltiusApp/server#5 deletes. Once that ships, Save 404s while the user believes they renamed themselves.Of the 15
/v1/...routes the portal calls, that is the only one absent from the server after the change. The staleness is exactly one row.Changes
updateDisplayName, and everything left dead by them@handle+ Copy for everyone;Change handlemodal for Pro+, matching the page's existing Email/password modalshandle_is_custom, so a lapsed Pro keeps their custom handle and loses only renaming — matching the server'seffective_tier_for_userThis is the only piece safe to land before the server and unsafe after. It is independently deployable —
PUT /v1/users/me/handlehas been live since the unified-invite server shipped, so this needs nothing from server#5.pnpm buildis clean (Next typecheck included) but this repo has no test suite, and the handle row has not been rendered in a browser. Review alone found two Important bugs in it — a successful rename reported as a failure, and a leading@rejected locally that the server strips — both fixed. Worth a look before merge.Note
A follow-up will make custom handles free for anyone with a verified email (the 14-day Pro trial makes the current paywall a no-op). The Pro-gating here is correct against today's server.